%-----------------------------------------------------------------------------
\chapter{Umsetzung}
%-----------------------------------------------------------------------------


\section{Gewählte Umsetzung}
%Haui hier wenn du Webservices weiter oben mit in die Arbeit nimmst nimmst du
% hier dann auch noch so wenig wie möglich Netzwerkbelastung bzw. oder so
% ähnlich hinzu.
% REST - weil viel weniger übertragen werden muß als bei SOAP und damit schneller
% vor allem bei Mobiltelefonen ist das wichtig und super denn mitunter gibt es
% Verbindungen welche schlecht sind (und diese Behauptung beweißt du NICHT -
% schon gar nicht statistisch).
Damit möglichst viele potentielle BenutzerInnen von der mobilen Applikation
profitieren können sowie um den finanziellen Aufwand für ebendiese so
gering wie möglich zu halten wurden die folgenden Technologien und
Softwareprodukte für die Umsetzung herangezogen.


\subsection{Apache Solr}
Apache Lucene ist eine Library für die Volltextsuche welche, unter anderem, in
eigene Softwareprojekte eingebunden werden kann um Volltextsuchfunktionalitäten
zur Verfügung zu stellen. Ihr Fokus liegt auf der zur Verfügungstellung von
performanten Volltextsuchindices und entsprechender Suchalgorithmen, zB der
Sortierung von Suchergebnissen untereinander um, je nach Suchbegriff, die
besten, d.h. relevantesten Ergebnisse, zuerst zurückgeben zu können. Für die
Umsetzung wird jedoch Apache Solr herangezogen da es ein Serverprodukt is
welches in einem Servlet Container \cite[S.1]{ServletContainerSpec} installiert
und ausgeführt werden kann. Es verwendet intern die Apache Lucene Library für
die Volltextsuche. Fokussiert sich im Unterschied zu dieser jedoch einerseits
darauf Dateninhalte über standardisierte Schnittstellen so einfach wie möglich
indizierbar zu machen. Sowie andererseits darauf die Volltextsuche, in den
jeweiligen indizierten Inhalten, über definierte Datenschnittstellen, zB
Webservices aber auch Java Libraries, zugänglich zu machen.


\subsection{REST-Webservices}
Da REST Webservices nur bestimmte Operationen unterstützen sowie nicht
ausschließlich XML als Übertragungsformat verwenden müssen bei gleichem Inhalt
weniger Daten über das Netzwerk übertragen werden als bei SOAP-Webservices. Dies
spielt insbesondere bei der Nutzung über mobile Endgeräte eine Rolle da die
Übertragungsraten bei mobilen Netzen schwanken und vor allem in ländlichen
Regionen sowie in Gebäuden sehr schlecht sein können und. Es ist daher notwendig
dass die mobile Applikation nur so wenig Netzwerkbandbreite in Anspruch nimmt
wie notwendig. Einerseits um die BenutzerInnen nicht unnötig lange auf
Suchergebnisse warten zu lassen sowie andererseits um der Ressourcenbegrenzung
von mobilen Endgeräten Rechnung zu tragen.






\subsection{Google Android}
Sowohl im vierten Quartal 2011, sowie auch im vierten Quartal 2012, war
Googles Android, mit stark steigender Tendenz, das meistinstallierte mobile
Betriebssystem auf neu verkauften Smartphones. Daher ist davon auszugehen
dass die meisten potentiellen BenutzerInnen mit der zu erstellenden Applikation
erreicht werden können wenn diese für Googles Betriebssystem für Smartphones
entwickelt wird. Die Erstellung einer mobilen Webseite für Smartphones wird
nicht in Betracht gezogen da eine auf dem Endgerät installierbare Applikation
erstellt werden soll welche vollen Zugriff auf alle Ressourcen des Gerätes
erlaubt.






\section{Alternative Umsetzungsmöglichkeiten}
Mit den folgende Technologien und Softwareprodukte können alternative
Umsetzungen in Betracht gezogen werden.



\subsection{Google Search Appliance}
Die Google Search Appliance bietet sehr viele Möglichkeiten die Indizierung von
Daten mittels sogenannter Connectoren anzupassen sowie ebenso Suchergebnisse
über Webservices abzufragen \cite[S.125 ff]{GSA-WWU}, \cite{Butler-GSA}. Damit
können alle funktionalen Anforderungen an den Volltextsuchserver welche für die
Applikation gefordert sind erfüllt werden. Da für die Verwendung jedoch
Lizenz-kosten entrichtet werden müssen kommt sie für die Erstellung der
beschriebenen Applikation aus finanziellen Gründen, im Rahmen dieser Arbeit,
nicht in Frage.


\subsection{Apache Lucene}
Da Apache Solr intern selbst die Apache Lucene Library für die Suche
verwendet ist die ausschließliche Verwendung von Apache Lucene für die
Lösung der vorliegenden Problemstellung möglich. Dies wird jedoch nicht
durchgeführt da es nicht sinnvoll ist jene Funktionalitäten welche von Apache
Solr bereits zur Verfügung gestellt werden abermals neu zu erstellen.


\subsection{Mobile Webseiten}
Aufgrund der Möglichkeiten von speziell für mobile Endgeräte erstellten HTML-5
kompatiblen Webseiten, auch in Bezug auf die Verwendung von Smartphonesensoren,
erscheint die beschriebene Applikation grundsätzlich unter Verwendung von
mobilen Webseiten umsetzbar. Jedoch nicht mit allen geforderten Funktionalitäten
zB dem direkten Import von Kontaktdaten in das Endgerät \cite[S.57
f]{EducatingPaper}.





\subsection{Applikationen für iOS, Windows Phone, Blackberry sowie Bada}
Aufgrund der großen Anzahl an von Dritten entwickelten Applikationen in den
jeweiligen Downloadplattformen sowie den vorhandenen Programmierschnittstellen
der einzelnen mobilen Betriebssysteme kann davon ausgegangen werden dass die
mobile Suchapplikation nach MitarbeiterInnen sowie Räumen von großen
Einrichtungen auch für diese Betriebssysteme entwickelt werden kann.






%-----------------------------------------------------------------------------
\section{Ergebnisse der Umsetzung}
%-----------------------------------------------------------------------------
Aus der gewählten Umsetzung ergeben sich die folgenden wichtigen
Zwischenschritte sowie Endergebnisse.


\subsection{Systemarchitektur}
Die Systemarchitektur der mobilen Suche nach MitarbeiterInnen sowie Räumen
stellt sich folgend dar, (siehe Abb.~\ref{SystemarchitekturImage}).

\begin{figure}[htbp]
    \centering
    \includegraphics [width=14.5cm,angle=0] {figures/Systemarchitektur.png}
    \caption{Darstellung der Systemarchitektur der mobilen Suchapplikation nach
    MitarbeiterInnen sowie Räumen}
    \label{SystemarchitekturImage}
\end{figure}





\subsection{Apache Solr}
Im einfachsten Fall kann der gesamte Suchserver, nach dem Download von der
Apache Solr Webseite \cite{SolrDownload} dem Entpacken der komprimierten Java
Archive \cite[S.7 f]{WAR-Format}, sowie dem Wechseln in den Beispielordner
"`example"', mittels des Befehls "`java -jar start.jar"' auf einem Rechner,
welcher eine aktuelle Java Laufzeitumgebung installiert hat, gestartet werden.
Dies des-halb da mit den notwendigen Java Archiven für den Volltextsuchserver
auch ein Servlet Container \cite{ServletContainerSpec} von der Apache Software
Foundation mit ausgeliefert wird. Im vorliegenden Fall wurde jedoch, in Hinblick darauf den Suchserver mit
allen notwendigen internen Konfigurationen, sowie spezifischen
Programmcodebestandteilen, als eigene Java Web Applikation im "`Web Application
Archive"' \cite{WAR-Format} Format deployen zu können, entschieden die einzelnen
Java Archive, aus welchen der Apache Solr Suchserver besteht, in ein eigenes
Software Projekt einzubinden.



\subsubsection{Installation}
Hierfür müssen alle Java Archive welche im Web Archive
\newline
"`apache-solr-3.6.2/dist/apache-solr-3.6.2.war"' des Distributionsarchives
vorhanden sind als Library im eigenen Software Projekt eingebunden
werden, (siehe Abb.~\ref{LibraryAuszug}). Weiters muss der gesamte Inhalt des
Ordners

\begin{figure}[htbp]
    \includegraphics [width=6cm,angle=0] {figures/LibraryAuszug.png}
    \caption{Auszug aus den Libraries welche um den Apache Solr Server deployen
    zu können eingebunden werden müssen}
    \label{LibraryAuszug}
\end{figure}



"`apache-solr-3.6.2/example/solr/conf"' des Distributionsarchives in das
Software Projekt kopiert werden. In diesem, sowie seinen
Unterordnern, befinden sich alle für den Betrieb des Suchservers notwendigen
Konfigurationsdateien. Um auf ebendiesen nach der Installation in einem Servlet
Container zugreifen zu können muss der Java Virtual Machine der Ort dieses
sogenannten "`Solr Home"' Verzeichnisses bekanntgegeben werden. Die hierfür
gewählte Möglichkeit ist das Setzen eines benannten Systemproperties zur
Laufzeit des Programmes. Da dies geschehen muss bevor zum ersten Mal auf den
Suchserver zugegriffen wird wird hierfür von der Klasse
"`ServletContextListener"' abgeleitet. Dies stellt, mit der entsprechenden
Registrierung dieser Klasse in der "`web.xml"' Datei sicher dass der
Programmcode sofort nach dem Erstellen der Ausführungsumgebung und vor der
Ausführung anderer Programmteile ausgeführt wird.

\lstinputlisting[language=Java]{figures/SystemProperty.java}


\subsubsection{Definition der Suchindexstruktur}
Suchindices, sowie zugehörende Datenstrukturen nach welchen nicht gesucht können
werden soll, welche aber im Zuge der Ausgabe von Suchergebnissen mit angezeigt
werden sollen, müssen in der Datei "`schema.xml"' definiert werden.
Diese ist im "`Solr Home"' Verzeichnis zu finden. Jede Solr Server Instanz kann
jedoch jeweils nur einen einzigen Suchindex verwalten.
Jedoch können bei Bedarf innerhalb einer Solr Installation mehrere Instanzen
definiert sowie betrieben werden. Für die vorliegende Applikation wird jedoch
aus Gründen der Einfachheit eine einzelne Solr Server Instanz und somit ein
einzelner Suchindex verwendet. Der Index beinhaltet eine
Typisierungsspalte welche angibt ob der vorliegende Datensatz Personen- oder
Raumdaten enthält.



\lstinputlisting[language=Xml]{figures/schema.xml}



\subsubsection{Apache Solrj}
Apache Solrj ist die Java Client Library über welche zur Laufzeit auf Solr
Server Instanzen zugegriffen werden kann um Dateninhalte der Suchindices zu
manipulieren sowie um Suchoperationen durchzuführen. Es kann mit der Library
über eigene Initialisierungsklasseen auf lokal laufende Instanzen, d.h. die Library wird auf demselben Rechner ausgeführt wie die
Suchserversoftware, zugegriffen
werden bzw. werden diese, so notwendig, beim erstmaligen Zugriff
gestartet.
 

\lstinputlisting[language=Java]{figures/StartServer.java}

Weiters unterstützt sie die Verwendung von annotierten Java Beans. Hierzu muss
die Klasse "`org.apache.solr.client.solrj.beans.Field"' importiert werden.


\lstinputlisting[language=Java]{figures/Bean.java}



\subsubsection{Import von Daten}
Der Import von Personen- sowie Raumdaten wird generisch mittels annotierter
Javabeans über die Solrj Library durchgeführt.


\lstinputlisting[language=Java]{figures/AddData.java}


\subsubsection{Suche durchführen}
Die Suche nach Personen sowie Räumen wird ebenfalls mittels annotierter
Java-beans über die Solrj Library durchgeführt. Es muss mittels der Klasse
\newline
"`org.apache.solr.client.solrj.SolrQuery"' unter Verwendung einer eigenen Syntax
übergeben werden welche Datenfelder auf welche Art und Weise durchsucht
\newline werden sollen.


\lstinputlisting[language=Java]{figures/SearchSolr.java}



\subsection{Rest-Webservices für Datenaustausch}
Für die Erstellung der REST-Webservices wird die Jersey Library  \cite{Jersey}
eingesetzt. Mit dieser können bestehende Klassen annotiert, dadurch deren
Dateninhalte transformiert, und darauf aufbauend die gewünschten Dateninhalten
in den gewünschten Formaten über das HTTP Protokoll zurückgegeben werden.
Hierfür muss zuallererst von der Klasse "`javax.ws.rs.core.Application"'
abgeleitet werden um der Library den Basiszugriffspfad mitteilen zu können sowie
welche Klassen Rest-Webservices zur Verfügung stellen.


\lstinputlisting[language=Java]{figures/RestWebserviceStart.java}

Die Klasse "`RestfulSearchWebservice"' definiert weitere Pfadstrukturen sowie
das tatsächlich einzeln aufrufbare Webservice für die Suche nach
MitarbeiterInnen.

\lstinputlisting[language=Java]{figures/RestWebservice.java}


Wichtig ist weiters dass wenn, wie im vorliegenden Fall, selbst erstellte
Klassen als Ergebnis per Webservice zurückgeliefert werden der Jersey Library mitgeteilt
werden muss wie damit umzugehen ist. Es muss, wiederum per Annotation, definiert
werden welche Ebene als Ausgangs- d.h. Rootelement für die Datengenerierung
anzusehen ist. Dies geschieht über Einbindung der Klasse
\newline
"`javax.xml.bind.annotation.XmlRootElement"' da Java XML Binding 
\newline \cite{JAXB} unterstützt wird. 

\lstinputlisting[language=Java]{figures/RestCustomClass.java}


Somit kann durch Aufruf des Urls
\newline
"`127.0.0.1/REST/search/Persons?searchTerm=haus"', wenn der Suchserver auf dem
lokalen Rechner läuft, eine Liste von  
MitarbeiterInnen im JSON-Format abgerufen werden deren Name das Wort "`haus"' an
beliebiger Stelle enthält.




\subsection{Smartphone Applikation für die Android Plattform}
Die Erstellung der Anwendung auf dem mobilen Endgerät ergibt folgende wichtige
Zwischenschritte und Ergebnisse.


\subsubsection{Vorgehensweise bei der Entwicklung}
Um Java basierende Applikationen für die Android Plattform zu erstellen wird das
grundsätzliche Layout der Sichten in einzelnen XML Dateien definiert. Aus diesen
XML Dateien wird, beim Speichervorgang vom, von Google für Eclipse
bereitgestelltem, Android Development Plugin \cite{ADT}, Java Code generiert.
Dieser Java Code kann in selbst erstellten Java Klassen verwendet werden um das
erstellte Layout zu manipulieren. Sämtliche Geschäfts- und Ablauflogik der
Applikation, sowie welche Layouts/Sichten wann, wie angezeigt werden, wird
ebenfalls in selbst entwickelentem Java Quellcode definiert. Die einzelnen
Layouts/Sichten einer Applikation mit den sie verwendenten Javaklassen werden,
in Anlehnung darauf dass BenutzerInnen damit Aktivitäten durchführen können,
"`Activities"' genannt. Activities können unter Verwendung von sogenannten
"`Intents"' programmatisch aufgerufen werden.


\subsubsection{Grundsätzliche Menüführung}
%Haui Aktionen
Als grundlegendes Element der Menüführung werden sogenannte "`Tabs"' eingesetzt.
Diese scheinen in jeder Hauptansicht der Applikation am unteren Rand auf und
verweisen auf die drei wichtigsten Aktionen welche mit der Applikation
durchgeführt werden können - Suche nach MitarbeiterInnen sowie Räumen und der Möglichkeit benutzerdefinierte applikationsweite Einstellungen vorzunehmen. Am oberen Rand der beiden Ansichten mit welchen Suchen durchgeführt werden
können befindet sich das Eingabefeld für die Suchbegriffe sowie rechts daneben
die Schaltfläche um die Suche mit dem eingegebenen Begriff auf dem Suchserver
durchzuführen, (siehe Abb.~\ref{TabScreenshot}).




\begin{figure}[H]
    \includegraphics [width=6cm,angle=0] {figures/TabScreenshot.png}
    \caption{Grundsätzliche Menüführung der Applikation mit "`Tabs"' unten sowie
    Feld für Suchbegriffeingabe und "`Suche"' Schaltfläche am oberen Rand}
    \label{TabScreenshot}
\end{figure}




Technisch wird dies umgesetzt indem in der Layout-XML-Datei ein sogenannter
"`TabHost"' Bereich definiert wird, welcher ein "`TabWidget"' enthält in
welchem wiederum in einem eigenem Layoutelement die einzelnen "`Tabs"'
dargestellt werden sollen.


\lstinputlisting[language=Xml]{figures/TabListing.xml}


Beim Start der Suchapplikation wird daher zuallererst jener Quellcode
ausgeführt welcher das grundsätzliche Layout mit den beinhaltenden "`Tabs"' aufbereitet.


\lstinputlisting[language=Java]{figures/TabListing.java}



\subsubsection{Suchfeld mit automatischem Fokus und Autocompletion}
Damit BenutzerInnen so wenig wie möglich eingeben müssen um die von Ihnen
gewünschten Informationen zu erhalten erhält das Suchfeld, wenn es beim Wechsel
in die Ansicht erstmalig angezeigt wird, automatisch den Fokus. Weiters ist es 
mit Autocompletion Funktionalität ausgestattet welche drei Vorschläge
unterbreitet, (siehe Abb.~\ref{AutoCompleteScreenshot}). 



\begin{figure}[H]
    \includegraphics [width=6cm,angle=0] {figures/AutoCompleteScreenshot.png}
    \caption{Autocompletion während der Eingabe von Suchbegriffen durch
    BenutzerInnen}
    \label{AutoCompleteScreenshot}
\end{figure}



Hierfür stellt die Android Plattform die eigene Layoutkomponente
"`AutoCompleteTextView"' zur Verfügung.






\lstinputlisting[language=Xml]{figures/AutoCompleteTextView.xml}


Damit BenutzerInnen in Bezug auf Ihre jeweiligen Eingaben auch Vorschläge
unterbreitet bekommen muss der Layoutkomponente während Ihrer Erstellung über
sogenannte "`Adapterklassen"' noch mitgeteilt werden welche Dateninhalte
vorgeschlagen werden sollen. Sowie auch welches Programmmodul benachrichtigt
werden sollen wenn BenutzerInnen Vorschläge anwählen.


\lstinputlisting[language=Java]{figures/AutoCompleteTextView.java}




\subsubsection{Suche durchführen}
Der tatsächliche Suchvorgang welcher alle Ergebnisse, nicht nur
Namensvervollständigungen, auflistet wird entweder durch Auswahl eines
vorgeschlagenen Suchbegriffes oder durch Auswählen der Schaltfläche "`Suchen"'
ausgelöst. Die Ergebnisse werden zur weiteren Auswahl in einer Auflistung
unterhalb des Suchfeldes präsentiert, (siehe Abb.~\ref{ResultView}). 



\begin{figure}[H]
    \includegraphics [width=6cm,angle=0] {figures/ResultView.png}
    \caption{Ergebnisse der Suche zur weiteren Auswahl unterhalb des Suchfeldes}
    \label{ResultView}
\end{figure}



Die Daten welche von der Auflistung angezeigt werden sollen müssen dieser,
analog zur Datenanzeige der Autocompletion beim Suchfeld, über eine
Adapterklasse zur Verfügung gestellt werden.


\lstinputlisting[language=Java]{figures/AdapterListing.java}






\subsubsection{REST-Webservices einbinden}
Sämtlicher Datenaustausch, zwischen der mobilen Applikation sowie dem
Suchserver basiert auf REST-Webservices. Da die Android Plattform neben den
standardmäßig bei Java vorhanden Klassen für den Netzwerkzugriff auch Bibliotheken für die Verarbeitung
von Daten im JSON Format beinhaltet müssen keine zusätz-lichen Libraries dem
Entwicklungsprojekt hinzugefügt sowie mit der Applikation mit deployed werden.


\lstinputlisting[language=Java]{figures/Webservice.java}



%Haui
%Das mit dem Suchbutton auch erwähnen


\subsubsection{Detaillierte Anzeige der Suchergebnisse}
Nach Auswahl einer Person in der Auflistung unterhalb des Suchfeldes wird eine
neue Ansicht präsentiert welche alle verfügbaren Details der gewählten Person
enthält, (siehe Abb.~\ref{PersonDetailView}). 


\begin{figure}[htbp]
    \includegraphics [width=6cm,angle=0] {figures/PersonenDetailView.png}
    \caption{Ansicht aller Details einer Person incl. der Möglichkeit
    zugeordnete Aktionen durchzuführen}
    \label{PersonDetailView}
\end{figure}



Bei Auswahl der einzelnen Detailinformationen wird die auf einem Smartphone
erwartbare Aktion durchgeführt.


  \begin{itemize}
    \item Telefon
    \newline 	
    Anruf zu angezeigter Telefonnummer wird automatisch durchgeführt
    \item eMailadresse
    \newline 
    eMailapplikation mit geöffneter Erstellungsansicht einer neuen Nachricht an 
    die angezeigte Adresse wird angezeigt
    \item Adresse
    \newline 
    Interaktiver Lageplan mit der angezeigten Adresse wird dargestellt
  \end{itemize}



Dies geschieht, mit Ausnahme des Aufrufes des interaktiven Lageplanes, durch
Verwendung des Attributes "`android:autoLink"', mit dem zugehörenden Wert, bei
dem Element "`TextView"' während der Definition des Layoutes im XML Format.


\lstinputlisting[language=XML]{figures/AutoLink.xml}



\subsubsection{Interaktiven Lageplan aufrufen}
Die automatische Verlinkung zur Anzeige eines interaktiven Lageplanes
funktionierte nur dann wenn es sich um eine US-amerikanische Adresse handelte.
Daher wird für die Anzeige des interaktiven Lageplanes ein Intent verwendet
welchem ein geographischer Uniform Resource Identifier (Geo-URI)
\cite[S.3]{Geo-URI} übergeben wird. 


\lstinputlisting[language=Java]{figures/LageplanIntent.java}


Dadurch wird die auf dem Android Smartphone installierte Lageplanapplikation
aufgerufen welche die gewünschte Adresse sowie, so gewünscht, die aktuelle
Position darstellt, (siehe Abb.~\ref{Lageplan}).


\begin{figure}[H]
    \includegraphics [width=6cm,angle=0] {figures/Lageplan.png}
    \caption{Ansicht des interaktiven Lageplanes welcher mit dem Intent
    aufgerufen wird}
    \label{Lageplan}
\end{figure}



\subsubsection{Kontaktdaten in das Adressbuch importieren}
Alle Kontaktinformationen welche in der detaillierten Ansicht der Suchergebnisse
aufscheinen, (siehe Abb.~\ref{PersonDetailView}, können mit Aktivieren der
Schaltfläche "`In Kontaktliste übernehmen"' in die Kontaktliste des mobilen
Endgerätes übernommen werden. Hierfür müssen die entsprechenden
Programmierschnittstellen und -klassen der Android Plattform verwendet werden. 


\lstinputlisting[language=Java]{figures/ContactImport.java}


\subsubsection{Suche nach Räumen}
Die Suche nach Räumen weist die gleichen technischen Anforderungen wie die Suche
nach MitarbeiterInnen auf und wird deshalb nicht näher dargestellt.


\subsubsection{Installation der Applikation}
Die Applikation läßt sich problemlos auf Smartphones, welche auf der aktuellen 
Android Plattform basieren, beispielsweise mit einer blauen Lupe als
Applikationsicon sowie dem Hinweistext "`Suche"' installieren, (siehe
Abb.~\ref{Installed}).


\begin{figure}[H]
    \includegraphics [width=6cm,angle=0] {figures/Installed.png}
    \caption{Ansicht des Icons mit Hinweistext der auf einem Android
    basierenden Smartphone installierten Applikation}
    \label{Installed}
\end{figure}














